56.4 KB · ⇊ 16 parts · ⤓ Micron 56.4 KB · ⤓ HTML 79.5 KB

top

Cache ([], auch []cite-ref-1[1]) bezeichnet in der Informationstechnik einen schnellen Pufferspeicher, der (wiederholte) Zugriffe auf vergleichsweise langsame Datenspeicher oder aufwendige Neuberechnungen zu vermeiden hilft. Daten, die bereits einmal geladen oder generiert wurden, verbleiben im Cache, so dass sie bei späterem Bedarf schneller aus diesem abgerufen werden können. Auch können Daten, die vermutlich bald benötigt werden, vorab vom Hintergrundmedium abgerufen und vorerst im Cache bereitgestellt werden (read-ahead).

Caches können als Hardwarestruktur (beispielsweise als Hauptspeicherchips) oder Softwarestruktur (beispielsweise als temporäre Dateien oder reservierter Speicherplatz) ausgebildet sein.

• Geschichte

• Neuere Geschichte

• Randbedingungen

• Nutzen

• Cachehierarchie

• Strategien

• Cachegröße

• Lokalitätsausnutzung

• Organisation

• Cache-Line/Cache-Zeile

• Blocknummer-Tags statt Adress-Tags

• Block/Satz-Aufteilung der Tags

• Cache Hits und Misses

• Arbeitsweise

• Verdrängungsstrategien

• Schreibstrategie

• Cache Flush

• Sonstiges

• Beispiele

• Prozessor-Cache

• Laufwerks-Cache

• Software-Caches

• Suchmaschinen-Cache

• DNS-Caching

• Weblinks

• Einzelnachweise

Das Konzept eines schnellen Zwischenspeichers, wie es hier beschrieben ist, wurde erstmals im April 1965 von M. V. Wilkes vorgestellt.cite-ref-2[2]

Cache ist ein Lehnwort, das in diesem Zusammenhang vermutlich erstmals bei IBM in Amerika aus dem Französischen entnommen wurde. Zumindest wird es bereits 1973 in einem Aufsatz von K. R. Kaplan, einem Mitarbeiter des Department of Computer Science am Livingston College der Rutgers University in New Jersey, verwendet.cite-ref-3[3] Seinen Ursprung hat es im französischen cache, das eigentlich die Bedeutung Versteck hat.cite-ref-4[4]cite-ref-5[5] Der Name verdeutlicht den Umstand, dass dem Verwender in der Regel der Cache und seine Ersatzfunktion für das angesprochene Hintergrundmedium verborgen bleibt. Wer das Hintergrundmedium verwendet, muss Größe oder Funktionsweise des Caches prinzipiell nicht kennen, denn der Cache wird nicht direkt angesprochen. Der Verwender „spricht das Hintergrundmedium an“, stattdessen „antwortet“ jedoch der Cache – genau auf die Art und Weise, wie auch das Hintergrundmedium geantwortet, also Daten geliefert hätte. Wegen der Unsichtbarkeit dieser zwischengeschalteten Einheit spricht man auch von Transparenz. Praktisch ist er eine gespiegelte Ressource, die stellvertretend für das Original sehr schnell reagiert.

Neben dem Zwischenspeichern von schon benutzten Daten haben moderne Caches die Aufgabe, zukünftig möglicherweise benötigte Daten schon in den Cache vorzuladen. Dies kann softwareunterstützt (PREFETCHT0, PREFETCHT1, PREFETCHT2, PREFETCHNTA) erfolgen (ab 1999/Pentium III) wie auch hardwareunterstützt durch Erkennen typischer Zugriffsmuster (ab 2000/Pentium 4).

Greifen außer dem den Cache verwendenden Gerät noch weitere auf das Hintergrundmedium zu, so kann es zu Inkonsistenzen kommen. Um auf ein identisches Datenabbild zugreifen zu können, ist es notwendig, vor dem Zugriff die Änderungen des Caches in das Hintergrundmedium zu übernehmen. Cachestrategien wie Write-Through oder Write-Back sind hier praktikabel. Im Extremfall muss ein kompletter „Cache Flush“ erfolgen.

Außerdem muss ggf. der Cache informiert werden, dass sich Daten auf dem Hintergrundmedium geändert haben und sein Inhalt nicht mehr gültig ist (Cache-Kohärenz). Stellt die Cachelogik das nicht sicher, so ergibt sich als Nachteil, dass inzwischen im Hintergrundmedium oder im Rechenprogramm erfolgte Änderungen nicht erkannt werden. Bei Verdacht auf Änderungen, oder um sicherzugehen, dass der aktuelle Stand berücksichtigt wird, muss der Benutzer explizit eine Cache-Aktualisierung veranlassen.

Die Ziele beim Einsatz eines Caches sind eine Verringerung der Zugriffszeit und/oder eine Verringerung der Anzahl der Zugriffe auf ein langsames Hintergrundmedium. Das bedeutet insbesondere, dass sich der Einsatz von Caches nur dort lohnt, wo die Zugriffszeit auch signifikanten Einfluss auf die Gesamtleistung hat. Während das z. B. beim Prozessorcache der meisten (skalaren) Mikroprozessoren der Fall ist, trifft es nicht auf Vektorrechner zu, wo die Zugriffszeit eine untergeordnete Rolle spielt. Deswegen wird dort üblicherweise auf Caches verzichtet, weil diese keinen oder nur wenig Nutzen bringen.

Ein weiterer wichtiger Effekt beim Einsatz von Caches ist die Verringerung der notwendigen Datenübertragungsrate an die Anbindung des Hintergrundmediums (siehe z. B. Speicherhierarchie); das Hintergrundmedium kann also „langsamer angebunden“ werden, was z. B. geringere Kosten ergeben kann. Weil oft der Großteil der Anfragen vom Cache beantwortet werden kann („Cache Hit“, s. u.), sinkt die Anzahl der Zugriffe und damit die notwendige Datenübertragungsrate. Zum Beispiel würde ein moderner Mikroprozessor ohne Cache selbst mit sehr kleiner Zugriffszeit des Hauptspeichers dadurch ausgebremst, dass nicht genügend Speicherbandbreite zur Verfügung steht, weil durch den Wegfall des Caches die Anzahl der Zugriffe auf den Hauptspeicher und damit die Anforderung an die Speicherbandbreite stark zunehmen würde.

Bei CPUs kann der Einsatz von Caches somit zum Verringern des Von-Neumann-Flaschenhalses der Von-Neumann-Architektur beitragen. Die Ausführungsgeschwindigkeit von Programmen kann dadurch im Mittel enorm gesteigert werden.

Ein Nachteil von Caches ist das schlecht vorhersagbare Zeitverhalten, da die Ausführungszeit eines Zugriffs aufgrund von Cache-Misses nicht immer konstant ist. Sind die Daten nicht im Cache, muss der Zugreifende warten, bis sie von dem langsamen Hintergrundmedium geladen wurden. Bei Prozessoren geschieht das oft bei Zugriffen auf bisher noch nicht verwendete Daten oder beim Laden des nächsten Programmbefehls bei (weiten) Sprüngen.

Da es technisch aufwändig und damit meist wirtschaftlich nicht sinnvoll ist, einen Cache zu bauen, der sowohl groß als auch schnell ist, kann man mehrere Caches verwenden – z. B. einen kleinen schnellen und einen deutlich größeren, jedoch etwas langsameren Cache (der aber immer noch viel schneller ist als der zu cachende Hintergrundspeicher). Damit kann man die konkurrierenden Ziele von geringer Zugriffszeit und großem Cacheumfang gemeinsam realisieren. Das ist wichtig für die Hit Rate.

Existieren mehrere Caches, so bilden diese eine Cachehierarchie, die Teil der Speicherhierarchie ist. Die einzelnen Caches werden nach ihrer Hierarchieebene (engl. level) durchnummeriert, also Level‑1 bis Level‑n oder kurz L1, L2 usw. Je niedriger die Nummer, desto näher liegt der Cache am schnellen „Benutzer“; die niedrigste Nummer bezeichnet daher den Cache mit der schnellsten Zugriffszeit, dieser wird als erstes durchsucht. Enthält der L1-Cache die benötigten Daten nicht, wird der (meist etwas langsamere, aber größere) L2-Cache durchsucht usw. Das geschieht solange, bis die Daten entweder in einer Cacheebene gefunden (ein „Cache Hit“, s. u.) oder alle Caches ohne Erfolg durchsucht wurden (ein „Cache Miss“, s. u.). In letzterem Fall muss auf den langsamen Hintergrundspeicher zugegriffen werden.

Tritt ein Cache Hit z. B. im L3-Cache auf, so werden die angeforderten Daten dem Zugreifer geliefert und zugleich in den L1-Cache übernommen; dafür muss dort eine Cache-Line weichen, die in den L2-Cache „absinkt“.

• Bei einem inklusiven Cache ist jeder Cache-Level für sich transparent, d. h. eine Cache-Line, die im L1-Cache ist, ist auch im L2- und L3-Cache vorhanden. Wird die Cache-Line aus dem L1-Cache „verdrängt“ (überschrieben mit Daten einer anderen Adresse), so muss sonst nichts unternommen werden – sie ist im L2-Cache ja immer noch vorhanden (sofern kein Write-Back o. Ä. notwendig ist).

• Bei einem exklusiven Cache ist eine Cache-Line einer Adresse nur einmal in allen Cache-Levels vorhanden. Eine Cache-Line zu Adresse A im L1-Cache ist nicht zusätzlich im L2- oder L3-Cache vorhanden. Wird sie aus dem L1-Cache verdrängt, so kann sie entweder gänzlich verworfen werden, oder muss explizit in den L2-Cache kopiert werden. Dort wird somit ebenfalls eine (andere) Cache-Line verdrängt, um Platz zu machen für die absinkende. Diese andere sinkt nun ihrerseits in den L3-Cache, wo somit eine dritte Cache-Line weichen muss.

Exklusive Cache-Hierarchien erzeugen deutlich mehr Datenverkehr zwischen den Caches. Dafür können so viele Cache-Lines bereitgehalten werden wie die Summe von L1-, L2- und L3-Cache-Größe, während beim inklusiven Cache nur die L3-Cache-Größe maßgebend ist.

Im Hardwarebereich weisen vor allem moderne CPUs zwei oder drei Cacheebenen auf; sonstige Geräte besitzen meist nur eine Cacheebene. Im Softwarebereich wird meist nur eine Cacheebene benutzt, eine prominente Ausnahme bilden Webbrowser, die zwei Ebenen nutzen (Arbeitsspeicher und Festplattenlaufwerk).

Um den Nutzen des meist um mehrere Zehnerpotenzen kleineren Caches im Vergleich zum Hintergrundspeicher zu maximieren, werden bei der Funktionsweise und Organisation eines Caches die Lokalitätseigenschaften der Zugriffsmuster ausgenutzt. Beobachtet man beispielsweise die Aktivität eines laufenden Programms auf einem Prozessor über ein kurzes Zeitintervall, so stellt man fest, dass wiederholt auf wenige und „immer dieselben“ kleinen Speicherbereiche (z. B. Code innerhalb von Schleifen, Steuervariablen, lokale Variablen und Prozedurparameter) zugegriffen wird. Deshalb können bereits kleine Caches mit einigen Kibibytes sehr wirksam sein.

Verarbeitet ein Algorithmus jedoch ständig neue Daten (z. B. Streaming-Daten), kann ein Cache keine Beschleunigung durch Mehrfach-Zugriffe bewirken, allenfalls geringfügig durch read-ahead.

Da Caches schnell sein sollen, verwendet man für sie meist eine andere (schnellere) Speichertechnologie als für den zu cachenden Speicher (zum Beispiel SRAM gegenüber DRAM, DRAM gegenüber Magnetscheibe usw.). Daher sind Caches meist wesentlich teurer in Bezug auf das Preis-Bit-Verhältnis, weshalb sie deutlich kleiner ausgelegt werden. Das führt dazu, dass ein Cache nicht alle Daten gleichzeitig vorrätig haben kann. Um das Problem zu lösen, welche Daten im Cache gehalten werden sollen, werden die Lokalitätseigenschaften der Zugriffe ausgenutzt:

Da sich Zugriffe auf Daten wiederholen (z. B. beim Abarbeiten einer Programmschleife), ist es eher wahrscheinlich, dass auf Daten, auf die schon einmal zugegriffen wurde, auch noch ein weiteres Mal zugegriffen wird. Diese Daten sollten also bevorzugt im Cache gehalten werden. Dadurch ergibt sich auch die Notwendigkeit, alte Daten, die lange nicht benutzt wurden, aus dem Cache zu entfernen, um Platz für neuere zu machen. Diesen Vorgang nennt man „Verdrängung“.

Da Programmcode und -daten nicht zufällig verstreut im Adressraum herumliegen, sondern „hintereinander“ und teilweise auch nur in bestimmten Adressbereichen angeordnet sind (Code-, Daten-, Stack-Segment, Heap usw.), ist es nach einem Zugriff auf eine bestimmte Adresse wahrscheinlich, dass auch auf eine „nahegelegene“ Adresse (sprich: Betrag der Differenz der beiden Adressen sehr klein) zugegriffen wird. Bei der Abarbeitung eines Programms wird z. B. ein Befehl nach dem anderen abgearbeitet, wobei diese „nacheinander“ im Speicher liegen (wenn kein Sprungbefehl dabei ist). Viele Datenstrukturen wie Arrays liegen ebenfalls „hintereinander“ im Speicher.

Cache-Nutzdaten werden in sogenannten Cache-Lines gespeichert, die in den 1990er Jahren 16 oder 32 Byte groß waren und heutzutage 64 oder 128 Bytes groß sind. Dies erfolgt aus folgenden Gründen

• Pro Cache-Lines werden 5 bis 7 Byte Metadaten benötigt. Daher ist es nicht sinnvoll, für jedes Nutzdaten-Byte jeweils 5 bis 7 Byte für die Metadaten vorzuhalten.

• Für die Implementierung von ECC-RAM sind immer nur Blocks von 8 Byte bis 64 Bytes schreibbar. Das betrifft Server-ECC-RAM wie auch generell Speicher ab DDR5-RAM.

• Speicher lesen immer Blocks von 64 oder 128 Byte. Einzelne Bytes sind seit DDR1-RAM nicht mehr lesbar.

• Meist werden ohnehin 8 bis 64 Byte für einzelne Lesezugriffe benötigt.

• Die Wahrscheinlichkeit ist hoch, dass benachbarte Speicherzellen in zeitlich kurzem Abstand ohnehin gelesen werden.

Ein Cache besteht aus einer (meist) festen Anzahl Einträgen, jeder Eintrag besteht aus:

Die eigentlichen Daten im Cache (64 bis 128 Byte bei aktuellen PC-Prozessoren)

höherwertige Adressbits, die sich nicht aus der Position in der Cache-Line und nicht aus dem Mapping im Cache ergeben.cite-ref-6[6]

Welche Daten wurden modifiziert und müssen zurückgeschrieben werden? (außer Write-Through-Caches)

Welche Daten sind in dieser Cache-Line gültig?

Welche Daten wurden am häufigsten oder vor kurzem benutzt oder auch nicht? (außer Direct Mapped-Cache)

Siehe auch unten #Einträge im Cache.

Eine Cache-Line ist die kleinste Verwaltungseinheit innerhalb des Caches von Prozessoren. Es handelt sich dabei um eine Kopie eines Speicherbereichs. Die Zugriffe vom Cache-Speicher zum Hauptprozessor oder zum Hauptspeicher erfolgen somit in einem einzigen, blockweisen Transfer. Die Größe einer Cache-Line beträgt 16 Bytes (Intel 80486), 32 Bytes (Intel Pentium bis Pentium III) und 64 Bytes (Intel Pentium 4 bis aktuelle Intel-Core-i-/AMD-Ryzen-Prozessoren).cite-ref-0-7-0[7] Die Minimallänge ergibt sich aus der Speicher-Busbreite multipliziert mit der Prefetch-Tiefe des Hauptspeichers und liegt heutzutage bei 64 oder 128 Bytes.cite-ref-8[8]

Im Nachfolgenden wird davon ausgegangen, dass Cache-Lines immer nur von Adressen gelesen und geschrieben werden, deren Adresse durch die (Byte-)Länge der Cache-Line teilbar ist.

Eine Cache-Line sei 64 Bytes groß. Es sei festgelegt, dass Daten nur gelesen und geschrieben werden können mit Startadressen z. B. 0, 64, 128, 192, 256, ... Das Hintergrundmedium ist also aufgeteilt in Blöcke, die gerade so groß wie eine Cache-Line sind.

Dann muss in den Adress-Tags nicht mehr die gesamte (Start-)Adresse der Daten gespeichert werden, sondern nur noch, der wievielte Datenblock auf dem Hintergrundmedium gecachet ist. Durch die Wahl passender Zahlen (Zweierpotenzen) im Binärsystem lassen sich so die Tags platzsparender speichern; das beschleunigt das Prüfen, ob eine angefragte Adresse im Cache enthalten ist.

Die Blöcke (Cache-Lines) eines Caches können in so genannte Sätze zusammengefasst werden. Für eine bestimmte Adresse ist dann immer nur einer der Sätze zuständig. Innerhalb eines Satzes bedienen alle Blöcke also nur einen Teil aller vorhandenen Adressen. Im Folgenden stehe die Variable m {\displaystyle m} für die Gesamtanzahl der Cacheblöcke und n {\displaystyle n} für die Anzahl der Blöcke pro Satz, die so genannte Assoziativität. Dann besteht der Cache also aus m n {\displaystyle {\tfrac {m}{n}}} Sätzen.

| Organisation | Anzahl der Sätze | Assoziativität |

|---|---|---|

| DM | m {\displaystyle m} | 1 |

| FA | 1 | m {\displaystyle m} ( = n {\displaystyle =n} ) |

| SA | m n {\displaystyle {\tfrac {m}{n}}} | n {\displaystyle n} |

Je nachdem, wie stark man diese Aufteilung vornimmt, spricht man von einer der drei Cache-Organisationsarten:

n = 1 {\displaystyle n=1} , d. h., jeder Block repräsentiert einen eigenen Satz, es gibt also so viele Sätze wie Blöcke. Somit ist für eine gegebene Adresse exakt ein Cacheblock zuständig. Es existiert also eine direkte Abbildung zwischen Hintergrundspeicheradresse und Cacheblöcken, daher der Name. Bei einer Anfrage an einen solchen Cache muss man nur einen einzelnen Cacheblock auslesen (genauer gesagt den zugehörigen Tag überprüfen, s. u.), was den Hardwareaufwand für die Tag-Vergleicher minimiert. Im Gegenzug ist die Effizienz des Caches eingeschränkt, da möglicherweise freie Cacheblöcke vorhanden sind, die nicht genutzt werden, siehe Conflict Miss unten.

n = m {\displaystyle n=m} , d. h., es gibt nur einen Satz, der alle Blöcke beinhaltet. Somit kann jede Adresse in jedem Cacheblock gecachet werden. Bei einer Anfrage an den Cache ist es daher notwendig, alle Cache-Tags zu überprüfen. Da Caches möglichst schnell sein müssen, wird das parallel ausgeführt, was den notwendigen Hardwareaufwand an Tag-Vergleichern vergrößert. Der Vorteil ist aber, dass der Cache stets Daten aufnehmen kann, solange noch ein beliebiger Cacheblock frei ist.

n {\displaystyle n} wird zwischen 2 und m 2 {\displaystyle {\tfrac {m}{2}}} gewählt, d. h., die Cacheblöcke sind in Sätzen zu je n {\displaystyle n} Blöcken angeordnet. Hier werden also m n {\displaystyle {\tfrac {m}{n}}} direkt abgebildete Caches vollassoziativ (also frei) angewählt. Diesen Cache nennt man dann n-fach satzassoziativ oder kurz n-fach assoziativ. Diese Cacheform stellt einen Kompromiss aus Hardwareaufwand und Effizienz des Caches dar: Gegenüber einem DM-Cache gewinnt man Effizienz, gegenüber einem FA-Cache spart man Hardware.

Die ersten beiden sind ein Spezialfall des satzassoziativen Caches. Der direkt abgebildete und der vollassoziative Cache lassen sich somit vom satzassoziativen Cache ableiten: n=1 führt zu einem direkt abgebildeten Cache, n=m zu einem vollassoziativen Cache.

Die wesentlichen Größen eines Caches sind:

• Die Größe der gespeicherten Daten (d. h. Größe des Caches): hier im Beispiel 64 KiB

• Die Größe des abzudeckenden Adressraumes: hier im Beispiel 4 GiB

• Die Länge einer Cache-Zeile: hier im Beispiel 64 Byte

• Die Granularität der Daten: hier im Beispiel 1 Byte

• Vorhandensein von Dirty- und Valid-Tags.

Der Cache besteht, unabhängig vom Aufbau, aus 64 KiB/64 Byte = 1024 Cache-Zeilen

| 31 | 30 | 29 | 28 | 27 | 26 | 25 | 24 | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |

|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|

| Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Byte-Position | Byte-Position | Byte-Position | Byte-Position | Byte-Position | Byte-Position |

Es gibt eine Cache-Gruppe, die alle 1024 Cache-Zeilen umfasst. Jedes Hauptspeicher-Datenwort kann in jeder beliebigen der 1024 Cache-Zeilen der einen Cache-Gruppe gespeichert werden. Es sind 1024 Komparatoren erforderlich, die log2(4 GiB/64 Byte) = log2(4 GiB)-log2(64 Byte) bits = 32-6 = 26 bits vergleichen müssen. An jeder Cache-Zeile hängen diese 26 Bit als Adress-Tag. Hardware-Aufwand:

• 1024 Komparatoren

• 1024 × 64 × 8 bit eigentlicher Cache

• 1024 × 26 bit Adress-Tag

• 1024 × 64 bit Valid-Tags

• 1024 × 64 bit Dirty-Tags

• 1024 × ? bit für die LRU-Tags

| 31 | 30 | 29 | 28 | 27 | 26 | 25 | 24 | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |

|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|

| Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | Byte-Position | Byte-Position | Byte-Position | Byte-Position | Byte-Position | Byte-Position |

Es gibt 1024 Cache-Gruppen mit je einer Cache-Zeile. Jedes Hauptspeicher-Datenwort kann nur in dieser zu seiner Adresse gehörenden Cache-Zeile gespeichert werden. Die Cache-Gruppe ergibt sich aus den Bit 15 bis 6 der Adresse. Es ist nur ein Komparator erforderlich, der log2(4 GiB)-log2(64 KiB) bits = 16 bits vergleichen muss. An jeder Cache-Zeile hängen diese 16 Bit als Adress-Tag. Hardware-Aufwand:

• Ein Komparator

• 1024 × 64 × 8 bit eigentlicher Cache

• 1024 × 16 bit Adress-Tag

• 1024 × 64 bit Valid-Tags

• 1024 × 64 bit Dirty-Tags

• Keine LRU-Tags

| 31 | 30 | 29 | 28 | 27 | 26 | 25 | 24 | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |

|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|

| Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | Byte-Position | Byte-Position | Byte-Position | Byte-Position | Byte-Position | Byte-Position |

Es gibt 512 Cache-Gruppen mit je zwei Cache-Zeilen. Jedes Hauptspeicher-Datenwort kann in einer der beiden zu seiner Adresse gehörenden Cache-Zeilen gespeichert werden. Die Cache-Gruppe ergibt sich aus den Bit 14 bis 6 der Adresse. Es sind zwei Komparatoren erforderlich, die log2(4 GiB)-log2(64 KiB)+1 bits = 17 bits vergleichen müssen. An jeder Cache-Zeile hängen diese 17 Bit als Adress-Tag. Hardware-Aufwand:

• Zwei Komparatoren

• 1024 × 64 × 8 bit eigentlicher Cache

• 1024 × 17 bit Adress-Tag

• 1024 × 64 bit Valid-Tags

• 1024 × 64 bit Dirty-Tags

• 1024 × 1 bit LRU-Tags

| 31 | 30 | 29 | 28 | 27 | 26 | 25 | 24 | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |

|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|

| Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | Länge Adress-Tag | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | benutzte Cache-Gruppe | Byte-Position | Byte-Position | Byte-Position | Byte-Position | Byte-Position | Byte-Position |

Es gibt 1024/2^n Cache-Gruppen mit je 2^n Cache-Zeilen. Jedes Hauptspeicher-Datenwort kann in einer der 2^n zu seiner Adresse gehörenden Cache-Zeilen gespeichert werden. Die Cache-Gruppe ergibt sich aus den Bit 15-(n-1) bis 6 der Adresse. Es sind 2^n Komparatoren erforderlich, die log2(4 GiB)-log2(64 KiB)+n bits = 16+(n-1) bits vergleichen müssen. An jeder Cache-Zeile hängen diese 16+(n-1) Bit als Adress-Tag. Hardware-Aufwand:

• 2^n Komparatoren

• 1024 × 64 × 8 bit eigentlicher Cache

• 1024 × (16+n-1) bit Adress-Tag

• 1024 × 64 bit Valid-Tags

• 1024 × 64 bit Dirty-Tags

• 1024 × mehrere bit LRU-Tags

Den Vorgang, dass die Daten einer Anfrage an einen Cache in selbigem vorrätig sind, bezeichnet man als „Cache Hit“ (dt. Cachetreffer), den umgekehrten Fall als „Cache Miss“ (dt. „Cache-Verfehlen“).

Um quantitative Maßzahlen für die Bewertung der Effizienz eines Caches zu erhalten, definiert man zwei Größen:

Die Anzahl der Anfragen, bei denen ein Cache Hit auftrat, geteilt durch die Anzahl der insgesamt an diesen Cache gestellten Anfragen. Wie man aus der Definition leicht sehen kann, liegt diese Größe zwischen Null und Eins. Eine Hit Rate von z. B. 0,7 (=70 %) bedeutet, dass bei 70 % aller Anfragen an den Cache dieser die Daten sofort liefern konnte und bei 30 % aller Anfragen passen musste.

Diese ist analog zur Hit Rate als die Anzahl der Anfragen definiert, bei denen die Daten nicht im Cache vorhanden waren geteilt durch die Anzahl der gesamten Anfragen. Es gilt: Miss Rate = 1 − Hit Rate.

Drei Arten von Cache Misses werden unterschieden:

Der Cache ist zu klein. Daten waren im Cache vorrätig, wurden aber wieder aus ihm entfernt. Erfolgt dann ein erneuter Zugriff auf diese Adresse, so wird dieser Miss als „Capacity Miss“ bezeichnet. Abhilfe schafft nur ein größerer Cache.

Durch die satzassoziative Organisation (gilt somit auch für DM-Caches) ist es möglich, dass in einem Satz nicht mehr genug Platz ist, während in anderen Sätzen noch freie Cacheblöcke vorhanden sind. Dann muss in dem überfüllten Satz ein Block entfernt werden, obwohl der Cache eigentlich noch Platz hat. Wird auf diesen entfernten Block erneut zugegriffen, so bezeichnet man diesen Cache Miss als „Conflict Miss“. Abhilfe schafft eine Erhöhung der Cacheblocks pro Satz – also eine Erhöhung der Assoziativität. Bei vollassoziativen Caches (welche nur einen Satz haben) gibt es prinzipbedingt keine Conflict Misses.

Als „Compulsory Miss“ oder auch „Cold Start Miss“ bezeichnet man den erstmaligen Zugriff auf eine Adresse, deren Daten sich noch nicht im Cache befinden, und zugleich hat der Cache noch freien Platz. Der Unterschied zu den anderen beides Misses ist der, dass hier keine Verdrängung stattfindet, sondern ein Block zum ersten Mal/neu beschrieben wird. Er ist nicht oder nur schwer zu verhindern. Moderne Prozessoren besitzen „Prefetcher“-Einheiten, die selbständig spekulativ Daten in die Caches laden, wenn dort noch Platz ist. Damit soll die Anzahl der Compulsory Misses verringert werden.

Diese drei Typen bezeichnet man auch kurz als „Die drei C“. In Multiprozessorsystemen kann beim Einsatz eines Cache-Kohärenz-Protokolls vom Typ Write-Invalidate noch ein viertes „C“ hinzukommen, nämlich ein „Coherency Miss“: Wenn durch das Schreiben eines Prozessors in einen Cacheblock der gleiche Block im Cache eines zweiten Prozessors hinausgeworfen werden muss, so führt der Zugriff des zweiten Prozessors auf eine Adresse, die durch diesen entfernten Cacheblock abgedeckt war, zu einem Coherency Miss.

Bei der Verwaltung des Caches ist es sinnvoll, immer nur die Blöcke im Cache zu halten, auf die auch häufig zugegriffen wird. Zu diesem Zweck gibt es verschiedene Ersetzungsstrategien. Eine häufig verwendete Variante ist dabei die LRU-Strategie (engl. least recently used), bei welcher immer der Block ausgetauscht wird, auf den am längsten nicht mehr zugegriffen wurde. Moderne Prozessoren (z. B. der AMD Athlon) implementieren meist eine Pseudo-LRU-Ersetzungsstrategie, die fast wie echtes LRU arbeitet, aber leichter in Hardware zu implementieren ist.

First In – First Out (FIFO)

Der jeweils älteste Eintrag wird verdrängt.

Least recently used (LRU)

Der Eintrag, auf den am längsten nicht zugegriffen wurde, wird verdrängt.

Dabei (FIFO, LRU) werden jedoch keine vollständigen Zeitstempel gespeichert, die eine relativ lange Integer-Zahl erfordern würden. Vielmehr werden wenige Bits verwendet (zwei sind häufig, aber auch nur eines ist möglich), um einen Cacheeintrag als mehr oder weniger häufig benutzt zu markieren. Die Aktualisierung der Bits erfolgt parallel zu einer Verdrängung.

Least frequently used (LFU)

Der am seltensten gelesene Eintrag wird verdrängt.

Ein zufälliger Eintrag wird verdrängt.

Daten werden im Cache in der Reihenfolge des Zugriffs abgelegt. Wenn auf ein Datum zugegriffen wird, wird für diesen Cacheblock ein Bit gesetzt. Bei einem Miss wird von vorne nach hinten nach dem ersten Datum ohne gesetztes Bit gesucht, dieses wird ersetzt. Bei allen dabei durchgegangenen Daten wird das Bit gelöscht. Es wird ebenfalls markiert, welches Datum zuletzt in den Cache geladen wurde. Von dort beginnt die Suche nach einem Datum, welches ersetzt werden kann.

Das Verfahren von Laszlo Belady, bei dem derjenige Speicherbereich verdrängt wird, auf den am längsten nicht zugegriffen werden wird, ist optimal. Es ist allerdings nur dann anwendbar, wenn der komplette Programmablauf im Voraus bekannt ist (d. h., er ist ein so genanntes Offline-Verfahren, im Gegensatz zu FIFO und LRU, die Online-Verfahren sind). Der Programmablauf ist aber fast nie im Voraus bekannt; deshalb kann das optimale Verfahren in der Praxis nicht eingesetzt werden. Allerdings kann der optimale Algorithmus als Vergleich für andere Verfahren dienen.

Bei einem Schreibzugriff auf einen Block, der im Cache vorhanden ist, gibt es prinzipiell zwei Möglichkeiten:

Beim Schreiben wird der zu schreibende Datenblock nicht sofort in der nächsthöheren Speicherebene abgelegt, sondern zunächst im Cache. Dabei entsteht eine Inkonsistenz zwischen Cache und zu cachendem Speicher. Letzterer enthält somit veraltete Information. Erst wenn das Wort aus dem Cache verdrängt wird, wird es auch in die nächsthöhere Speicherebene geschrieben. Dazu bekommt jeder Cacheblock ein sogenanntes Dirty Bit, das anzeigt, ob der Block beim Ersetzen zurückkopiert werden muss. Das führt bei Speicherzugriff durch andere Prozessoren oder DMA-Geräte zu Problemen, weil diese veraltete Informationen lesen würden. Abhilfe schaffen hier Cache-Kohärenz-Protokolle wie zum Beispiel MESI für Uniform-Memory-Access-Systeme.

Der zu schreibende Block wird sofort in der nächsthöheren Speicherebene abgelegt. Damit ist die Konsistenz gesichert. Damit der Prozessor nicht jedes Mal warten muss, bis der Block in der nächsthöheren Speicherebene (die ja langsamer als der Cache ist) abgelegt ist, benutzt man einen Pufferspeicher (write buffer). Wenn dieser voll läuft, muss der Prozessor jedoch anhalten und warten.

Analog zu Obigem gibt es bei einem Schreibzugriff auf einen Block, der nicht im Cache vorhanden ist, prinzipiell ebenso zwei Möglichkeiten:

Wie bei einem normalen Cache Miss wird der Block aus der nächsthöheren Speicherebene geholt. Die entsprechenden Bytes, die durch den Schreibzugriff geändert wurden, werden danach im gerade frisch eingetroffenen Block überschrieben.

Es wird am Cache vorbei in die nächsthöhere Speicherebene geschrieben, ohne dass der dazugehörige Block in den Cache geladen wird. Das kann für manche Anwendungen Vorteile bringen, bei denen viele geschriebene Daten nie wieder gelesen werden. Durch die Verwendung von non-write-allocate verhindert man das Verdrängen von anderen, möglicherweise wichtigen Blöcken und reduziert somit die Miss Rate.

Einige Befehlssätze enthalten Befehle, die es dem Programmierer ermöglichen, explizit anzugeben, ob zu schreibende Daten am Cache vorbeizuschreiben sind.

Normalerweise wird entweder die Kombination write-back mit write-allocate oder write-through mit non-write-allocate verwendet. Die erste Kombination hat den Vorteil, dass aufeinander folgende Schreibzugriffe auf denselben Block (Lokalitätsprinzip) komplett im Cache abgewickelt werden (bis auf den ersten Miss). Dies gibt im zweiten Fall keinen Vorteil, da sowieso jeder Schreibzugriff zum Hauptspeicher muss, weshalb die Kombination write-through mit write-allocate eher unüblich ist.cite-ref-9[9]

Ein Cache Flush („Pufferspeicher-Leerung“) bewirkt das komplette Zurückschreiben des Cacheinhaltes in den Hintergrundspeicher. Dabei bleibt der Cacheinhalt meist unangetastet. Ein solches Vorgehen ist nötig, um die Konsistenz zwischen Cache und Hintergrundspeicher wiederherzustellen. Notwendig ist das zum Beispiel immer dann, wenn Daten aus dem Hauptspeicher von externen Geräten benötigt werden, unter anderem bei Multiprozessor-Kommunikation oder bei der Übergabe eines als Ausgabepuffer benutzten Teils des Hauptspeichers an den DMA-Controller.

Für jeden Cacheblock wird im Cache folgendes gespeichert:

• Die eigentlichen Daten

• Der Tag (ein Teil der Adresse)

• Mehrere Statusbits, wie:

modified bzw. dirty Gibt an, ob dieser Cacheblock geändert wurde (nur beim Write-Back-Cache). diverse Statusbits je nach Cache-Kohärenz-Protokoll, z. B. je ein Bit für:

owner Äquivalent zu „modified & shared“. Gibt an, dass der Block geändert wurde und in anderen Caches vorhanden ist. Der Owner ist dafür verantwortlich, den Hauptspeicher zu aktualisieren, wenn er den Block aus seinem Cache entfernt. Derjenige Prozessor, der zuletzt auf den Cacheblock schreibt, wird neuer Owner.

exclusive Gibt an, dass der Block nicht geändert wurde und in keinem anderen Cache vorhanden ist.

shared Hat teilweise unterschiedliche Bedeutungen: Bei MESI gibt das an, dass der Block nicht geändert wurde, aber auch in Caches anderer Prozessoren vorhanden ist (dort ebenso unverändert). Bei MOESI bedeutet es nur, dass der Block in anderen Prozessorcaches vorhanden ist. Hier ist auch erlaubt, dass der Block verändert wurde, also inkonsistent zum Hauptspeicher ist. In diesem Fall gibt es aber einen „Owner“ (s. o.), der für das Aktualisieren des Hauptspeichers verantwortlich ist.

invalid Zeigt an, ob der Block frei (also mit ungültigen Daten befüllt) oder belegt (also mit gültigen Daten befüllt) ist.

Ein Cache ist „heiß“, wenn er optimal arbeitet, also gefüllt ist und nur wenige Cache Misses hat; ist das nicht der Fall, gilt der Cache als „kalt“. Nach Inbetriebnahme ist ein Cache zunächst kalt, da er noch keine Daten enthält und häufig zeitraubend Daten nachladen muss, und wärmt sich dann zunehmend auf, da die zwischengelagerten Daten immer mehr den angeforderten entsprechen und weniger Nachladen erforderlich ist. Im Idealzustand werden Datenzugriffe fast ausschließlich aus dem Cache bedient und das Nachladen kann vernachlässigt werden.

Siehe auch

:

Befehlscache

Bei Hauptprozessoren kann der Cache direkt im Prozessor integriert oder extern auf der Hauptplatine (früher weiter verbreitet, heute eher untypisch) platziert sein. Oft gibt es mehrere Ebenen (Levels), die aufeinander aufbauen. Kleinere Level sind dabei typischerweise schneller, haben aber aus Kostengründen eine geringere Größe. Je nach Ort des Caches arbeitet dieser mit unterschiedlichen Taktfrequenzen: Der L1 (Level 1, am nächsten an der CPU) ist fast immer direkt im Prozessor (d. h. auf dem Die) integriert und arbeitet daher mit dem vollen Prozessortakt – also u. U. mehreren Gigahertz. Ein externer Cache hingegen wird oft nur mit einigen hundert Megahertz getaktet.

Aktuelle Prozessorarchitekturen (zum Beispiel AMD Zen 4, Intel Ice Lake, IBM Power10)cite-ref-0-7-1[7] besitzen überwiegend drei Cache-Level: L1, L2 und L3. Gängige Größen für L1-Caches sind 4 bis 320 KiB pro Prozessorkern (meist gibt es einen für Daten und einen für Befehle), der L2-Cache ist 64 KiB bis 32.768 KiBcite-ref-10[10] (meist ebenfalls pro Kern), der L3-Cache 2 bis 1152 MiBcite-ref-11[11] (für alle Kerne gemeinsam). Prozessorcache als Extra-Chip auf der Hauptplatine wird heute nicht mehr gebaut, als Extra-Die im selben Chip-Gehäuse (siehe Multi-Chip-Modul) nur noch selten.

In jedem Fall ist eine Protokollierung erforderlich, um die Kohärenz der Daten (z. B. zwischen Caches und Hauptspeicher) sicherzustellen. Dazu dienen Flags, die einen Speicherbereich (typischerweise eine ganze line von 64 Byte) als „dirty“, also geändert, markieren (s. o. bei Schreibstrategie). Das Problem verschärft sich bei mehreren Cache-Levels und mehreren Prozessoren oder Prozessorkernen.

Die Cachekonsistenz ist sowohl bei mehreren aktiven Geräten auf dem Datenbus als auch bei mehreren zusammengeschalteten Prozessoren (Mehrprozessorsysteme) zu beachten.

Bei Mehrprozessorsystemen unterscheidet man unter anderem nach flynnscher Klassifikation zwischen SIMD- und MIMD-Strukturen (Single/Multiple Instruction – Multiple Data). Bei MIMD-Systemen ist die Wahrscheinlichkeit hoch, dass verschiedene Prozessoren auf verschiedene Speicherbereiche zugreifen, bei SIMD dagegen kleiner. Danach lässt sich die Cache-Konfiguration einstellen.

Moderne Prozessoren haben getrennte L1-Caches für Programme und Daten (Lese- und Schreibcache), teilweise ist das auch noch beim L2 der Fall (Intel Itanium 2). Man spricht hier von einer Harvard-Architektur. Das hat den Vorteil, dass man für die unterschiedlichen Zugriffsmuster für das Laden von Programmcode und Daten unterschiedliche Cachedesigns verwenden kann. Außerdem kann man bei getrennten Caches diese räumlich besser zu den jeweiligen Einheiten auf dem Prozessor-Die platzieren und damit die kritischen Pfade beim Prozessorlayout verkürzen. Des Weiteren können Instruktionen und Daten gleichzeitig gelesen/geschrieben werden, wodurch der Von-Neumann-Flaschenhals weiter verringert werden kann. Ein Nachteil ist, dass selbstmodifizierender Code gesondert behandelt werden muss, was seine Ausführung stark verlangsamt. Allerdings wird diese Technik aus Sicherheitsgründen und weil sie oft schwer verständlich, schwer prüfbar und daher nur schlecht zu warten ist, heute ohnehin nur noch sehr selten verwendet.

Bei Festplattenlaufwerken befindet sich der Cache auf der Steuerplatine (siehe Festplattencache) oder einer separaten Platine, dem Host-Bus-Adapter.

Die Größe beträgt bei aktuellen Festplatten – je nach vom Hersteller vorgesehenen Einsatzzweck der Festplatte – zwischen 8 und 256 MiB.cite-ref-0-7-2[7]

Die meisten optischen Laufwerke besitzen Caches, um die oft im dreistelligen Millisekundenbereich liegenden Zugriffszeiten und Schwankungen im Datenstrom (z. B. durch Synchronisierungsprobleme) aufzufangen.

Caches können auch bei Software genutzt werden, dabei ist dasselbe Prinzip wie bei der Hardwareimplementierung gemeint: Daten werden für einen schnelleren Zugriff auf ein schnelleres Medium zwischengespeichert.

Beispiele: Festplattencache (vom Betriebssystem verwaltet)

Festplatte → Hauptspeicher

Anwendungsdaten (Memoisation)

Berechnung → Hauptspeicher

Netz → (Festplatte/Arbeitsspeicher)

Datenbank → HTML-Datei (HTTP Caching)

Software-Caches, welche die Festplatte als schnelleres Medium verwenden, werden meist in Form von temporären Dateien angelegt.

Man spricht auch von Caching, wenn ein Betriebssystem gewisse Ressourcen – wie z. B. Programmbibliotheken oder Schriftarten – vorerst im Arbeitsspeicher belässt, obwohl sie nach Ende ihrer Benutzung nicht mehr gebraucht werden. Solange kein Speichermangel herrscht, können sie im Arbeitsspeicher verbleiben, um dann ohne Nachladen von der Festplatte sofort zur Verfügung zu stehen, wenn sie wieder gebraucht werden. Wenn allerdings die Speicherverwaltung des Betriebssystems einen Speichermangel feststellt, werden diese Ressourcen als erste gelöscht.

Der Suchmaschinen-Cache ist der Lesecache einer Suchmaschine. Eine Suchmaschine besitzt drei Kernkomponenten:

1. Ein Webcrawler durchsucht das World Wide Web nach neuen oder veränderten Webseiten und lädt sie (zusätzlich) in

2. den Suchmaschinen-Cache, über den regelmäßig verschiedene Indizes erstellt werden. Über diese Indizes sucht

3. ein Suchalgorithmus, der gemäß einer Benutzeranfrage passende Webseiten finden soll.

Die Inhalte aller Webseiten, die die Suchmaschine als Basisdaten für Benutzeranfragen berücksichtigt, werden im Suchmaschinen-Cache zwischengespeichert. Die Server einer Suchmaschine können nicht für jede Abfrage jede Webseite in Echtzeit auf die aktuellsten Inhalte durchsuchen; stattdessen wird in einem Index über dem Cache gesucht.

Im Allgemeinen kann ein Webseiten-Betreiber Änderungen seiner Webseiten an die Suchmaschine melden, dann fragt der Webcrawler die Seite baldmöglichst erneut ab; ansonsten prüft der Webcrawler jede Webseite in regelmäßigen Abständen – die Cache-Inhalte können also veraltet sein. Eine Webseite kann dem Crawler einen Hinweis geben, wie häufig sie sich im Allgemeinen ändert. Suchmaschinen gehen mit dieser Information mitunter verschieden um.

Die in Deutschland verbreitetste Suchmaschine ist Google; deren Cache-, Indizier- und Suchstrategien wird daher besonders hohes Interesse zuteil. Die Webcrawler-Frequenz, mit der Webseiten geprüft werden, liegt bei Google bei den meisten Webseiten zwischen einer und vier Wochen („[…] Inhalt wird in der Regel alle 7 Tage aktualisiert“cite-ref-google-cache-12-0[12]). Gemeldete Webseiten untersucht der sogenannte Googlebot.

→

Hauptartikel

:

DNS-Caching

Im Domain Name System finden Caches Anwendung, welche die Ergebnisse einer Namensauflösung in einem lokalen Cache vorübergehend zwischenspeichern. Folgende identische DNS-Anfragen können aus dem Cache bedient werden ohne den Nameserver erneut anfragen zu müssen, wodurch die Performance erhöht wird. Bei DNS befinden sich in der Regel Namensserver, Cache und Anwendung auf verschiedenen über das Internet verbundenen Systemen.

Commons

: Cache

– Sammlung von Bildern, Videos und Audiodateien

Wiktionary: Cache

– Bedeutungserklärungen, Wortherkunft, Synonyme, Übersetzungen

• Artikel über CPU-Cache bei arstechnica.com (englisch)

• Cache und Hauptspeicher Online-Seminar

• Kurzüberblick Cache im Elektronik-Kompendium

cite-note-11. ↑ Cache auf duden.de

cite-note-22. ↑ M. V. Wilkes: Slave Memories and Dynamic Storage Allocation. In: Institute of Electrical and Electronics Engineers (Hrsg.): IEEE Transactions on Electronic Computers. EC-14, April 1965, ISSN 0367-7508, doi:10.1109/PGEC.1965.264263 (englisch).

cite-note-33. ↑ K.R. Kaplan, R.O. Winder: Cache-based Computer Systems. In: Institute of Electrical and Electronics Engineers (Hrsg.): Computer. Band 6, Nr. 3, März 1973, S. 30–36, doi:10.1109/C-M.1973.217037 (englisch).

cite-note-44. ↑ Wörterbuch Französisch. Übersetzung: cache. Éditions Larousse, archiviert vom Original (nicht mehr online verfügbar) am 28. Januar 2013; abgerufen am 20. November 2018.

cite-note-55. ↑ cache. In: Oxford Learner's Dictionaries. University of Oxford, abgerufen am 9. September 2023 (englisch).

cite-note-66. ↑ Ein 16-fach assoziativer 16 MByte-Cache bei unterstützten 128 GByte muss hier z. B. die Adressbits 37 bis 20 (insgesamt 18 bit) speichern.

cite-note-0-77. ↑ Stand: Januar 2024

cite-note-88. ↑ 80486: 16 Byte, ab Pentium: 32 Byte, ab Pentium 4: 64 Byte, Apple M1: 64 und 128 Byte

cite-note-99. ↑ John Hennessy, David Patterson: Computer Architecture. A Quantitative Approach. 4th Edition. Morgan Kaufmann Publishers, ISBN 978-0-12-370490-0 (englisch), S. C-11–C-12

cite-note-1010. ↑ IBMs Telum-Architektur: 128 KB L1-Daten, 128 KByte L1-Befehle, 32 MByte L2, jeweils pro Kern

cite-note-1111. ↑ https://www.techpowerup.com/cpu-specs/epyc-9684x.c3253 EOYC 9684X: 1152 MByte L3

cite-note-google-cache-1212. ↑ „Ein kurzer Einblick in die Funktionalität des Google-Caches (Memento vom 28. Juli 2017 im Internet Archive)“ (Mit Suchfunktion)